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Foreword 



This Technical Specification (TS) has been produced by ECMA on behalf of its members and those of the European 
Telecommunications Standards Institute (ETSI). 



Brief history 



The present document is one of a series of ECMA Standards defining the interworking of services and signalling 
protocols deployed in corporate telecommunication networks (CNs). The series uses telecommunication concepts as 
developed by ITU-T and conforms to the framework of International Standards on Open Systems Interconnection as 
defined by ISO/IEC. It has been produced under ETSI work item DTS/ECMA-00216. 

The present document defines the signalling protocol interworking for basic services between a Private Integrated 
Services Network (PISN) and a packet-based private telecommunications network based on the Internet Protocol (IP). It 
is further assumed that the protocol for the PISN part is that defined for the Q reference point (QSIG) and that the 
protocols for the IP-based network are based on ITU-T Recommendation H.323 [9]. 

The present document is based upon the practical experience of ECMA member companies and the results of their 
active and continuous participation in the work of ISO/IEC JTCl, ITU-T, ETSI and other international and national 
standardization bodies. It represents a pragmatic and widely based consensus. 

The present document is contributed to ISO/IEC JTCl under the terms of the fast-track procedure, for adoption as an 
ISO/IEC International Standard. 

The present document has been adopted by the General Assembly of December 2001. 
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Scope 



The present document specifies signalling interworking between "QSIG" and "H.323" in support of basic services 
within a Corporate telecommunication Network (CN). 

"QSIG" is a signalling protocol that operates at the Q reference point between Private Integrated services Network 
exchange (PINX) within a Private Integrated Services Network (PISN). The Q reference point is defined in 
ECMA-133 [1]. A PISN provides circuit-switched basic services and supplementary services to its users. QSIG is 
specified in other ECMA Standards, in particular ECMA-I43 [2] (call control in support of basic services). 

"H.323" is a set of signalling protocols for the support of voice or multimedia communication within a packet network, 
in particular a packet network that uses the Internet Protocol (IP) as its network layer protocol (IP network). H.323 
signalling protocols operate between endpoints in an IP network, either indirectly via one or more gatekeepers, or 
directly. An endpoint can be a terminal or a gateway to another network. H.323 is an "umbrella" recommendation 
referring to various ITU-T Recommendations, in particular H. 225.0 [6] and H.245 [8] (basic communication 
capabilities). 

The present document specifies signalling interworking for basic services that provide a bidirectional transfer capability 
for speech, DTMF, facsimile and modem media between a PISN employing QSIG and a private IP network employing 
H.323. The present document specifies requirements for establishing user information (audio) connections between the 
PISN and the IP network, but protocols for transmitting audio in the IP network and for signalling in order to establish 
and close down audio transmission in the IP network are outside the scope of the present document. Supplementary 
services are outside the scope of the present document. 

Interworking between QSIG and H.323 permits a call originating at a user of a PISN to terminate at a user of a private 
IP network, or a call originating at a user of a private IP network to terminate at a user of a PISN. 

Interworking between a PISN employing QSIG and a public IP network employing H.323 is outside the scope of the 
present document. However, the functionality specified in the present document is in principle applicable to such a 
scenario when deployed in conjunction with other relevant functionality (e.g. number translation, security functions, 

etc.). 

Although two such gateways can operate as peers on either side of an IP network (whereby the IP network provides 
interconnection between two PISNs), special support for this situation (e.g. tunnelling of QSIG information through the 
IP network) is outside the scope of the present document. 

Although two such gateways can operate as peers on either side of a PISN (whereby the PISN provides interconnection 
between two IP networks), special support for this situation (e.g. tunnelling of H.323 information through the PISN) is 
outside the scope of the present document. 

The present document is applicable to any interworking unit that can act as a gateway between a PISN employing QSIG 
and a private IP network employing H.323. 



2 Conformance 

In order to conform to the present document, a gateway shall satisfy the requirements identified in the Implementation 
Conformance Statement (ICS) proforma in annex A. 
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4 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

4.1 External definitions 

The present document uses the following terms defined in other documents: 

- Call (ECMA-307 [10]) 

- Corporate telecommunication network (CN) (ECMA-307 [10]) 
Endpoint (ITU-T Recommendation H.323 [9]) 
Gatekeeper (ITU-T Recommendation H.323 [9]) 
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- Private Integrated Services Network (PISN) (ECMA-307 [10]) 

- Private Integrated services Network eXchange (PINX) (ECMA-133 [1]) 

Additionally the definitions in ECMA-143 [2] and ITU-T Recommendation H.323 [9] apply as appropriate. 

4.2 Other definitions 

4.2.1 Gateway 

A gateway as defined in ITU-T Recommendation H.323 [9] specifically for the purpose of interworking with a network 
employing QSIG. 

4.2.2 IP network 

A network, unless otherwise stated a CN, offering connectionless packet-mode services based on the Internet Protocol 
(IP) as the network layer protocol. 

4.2.3 Ring-back tone 

An in-band tone or announcement played to the calling user during the alerting of the called user. 



Acronyms 



CN Corporate telecommunication Network 

ICS Implementation Conformance Statement 

IP Internet Protocol 

NPI Numbering Plan Identification 

PINX Private Integrated services Network eXchange 

PISN Private Integrated Services Network 

PNP Private Numbering Plan 

TON Type Of Number 



Architecture 



The present document specifies signalling protocol interworking aspects of a gateway between a PISN employing QSIG 
signalling and an IP network employing H.323 signalling. The gateway appears as a PINX to other PINXs in the PISN. 
The gateway appears as an H.323 endpoint to other H.323 entities in the IP network, these being: 

• other endpoints (terminals, gateways or multipoint control units) that originate calls via the gateway to the PISN 
and terminate calls via the gateway from the PISN; 

• gatekeepers, including the gatekeeper with which the gateway registers and other gatekeepers involved in call 
routing. 

This environment is illustrated in figure 1 . 
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Figure 1: Environment 

In addition to the signalling interworking functionality specified in the present document, it is assumed that the gateway 
also includes the following functionality: 

• one or more physical interfaces on the PISN side supporting one or more inter-PINX links, each link providing 
one or more constant bit rate channels for media information and a reliable layer 2 connection for transporting 
QSIG signalling messages; and 

• one or more physical interfaces on the IP network side supporting, through layer 1 and layer 2 protocols, IP as 
the network layer protocol and UDP and TCP as transport layer protocols, these being used for the transport of 
media information and H.323 signalling protocols; 

• a means of transferring media information in each direction between the PISN and the IP network, including, as 
a minimum, packetization of media information sent to the IP network and de-packetization of media 
information received from the IP network. 

NOTE: The gateway can be decomposed as described in clause 6.3.1 of H.323 [9]. In this case, the signalling 

interworking aspects of the gateway, as specified in the present document, can be expected to reside in the 
Media Gateway Controller (MGC). 

The protocol model relevant to signalling interworking functionality of a gateway is shown in figure 2. 



IP network 



Interworking 
function 


H.225.0 
RAS 


H.225.0 

call 
control 


H.245 




QSIG 
layer 3 


UDP/TCP 


IP 


IP network 
lower layers 


PISN lower 
layers 



PISN 



Figure 2: Protocol model 

The relevant signalling protocols on the IP network side of the gateway are: 

• H.225.0 Registration, Admission and Status (RAS); 

• H.225.0 call control, for the purpose of establishing and clearing down sessions between endpoints; and 

• H.245, for the purpose of supervising resources during a session. 

The interworking function therefore provides interworking between QSIG on the PISN side and H.225.0 RAS, H.225.0 
call control and H.245 on the IP network side. 
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7 General requirements 



In order to conform to the present document, a gateway shall support QSIG in accordance with ECMA-143 [2] and 
shall support H.323 in accordance with H.323 [9] version 4 or later (including H.225.0 [6] version 4 or later and 
H.245 [8] version 7 or later). The gateway shall be able to interoperate with other H.323 entities in accordance with the 
provisions of H.323 [9] version 4. 

The gateway shall support calls from QSIG to an H.323 endpoint and calls from an H.323 endpoint to QSIG. 

The gateway shall be able to discover and register with a gatekeeper. The means of doing this is outside the scope of the 
present document, but should be in accordance with H.323 RAS procedures. The procedures specified in the present 
document for call establishment apply after successful registration. 

The gateway may also be able to operate without registering with a gatekeeper. In this case the means by which the 
gateway maps QSIG numbers to IP addresses for routing calls from QSIG to an H.323 endpoint is outside the scope of 
the present document. 

For operation with a gatekeeper, the gateway shall be able to employ admission and disengage procedures. The gateway 
may support pre-granted admission procedures. 

For operation with a gatekeeper, the gateway shall be able to support both direct call signalling and gatekeeper-routed 
call signalling. Unless pre-granted admission procedures apply, choice of call signalling method shall be in accordance 
with instructions from the gatekeeper at the time of admission. 



8 Message mapping requirements 

8.1 IVIessage validation and handling of protocol errors 

The gateway shall validate received QSIG messages in accordance with the requirements of ECMA-143 [2] and shall 
act in accordance with ECMA-143 [2] on detection of a QSIG protocol error. The gateway shall validate received 
H.225.0 messages in accordance with the requirements of ITU-T Recommendations H.323 [9] and H.225.0 [6] and shall 
act in accordance with H.323 [9] and H.225.0 [6] on detection of an H.225.0 protocol error. Requirements of this clause 
for acting on a received QSIG or H.225.0 message apply only to a received message that has been successfully 
validated. 

NOTE 1: These rules mean that an error detected in a received message will not be propagated to the other side of 
the gateway. However, there can be an indirect impact on the other side of the gateway, e.g. the initiation 
of call clearing procedures. 

The gateway shall handle the QSIG RESTART, RESTART ACKNOWLEDGE, STATUS and STATUS ENQUIRY 

messages and the QSIG Restart indicator and Call state information elements in accordance with ECMA-143 [2] and 
shall not propagate these items to the H.323 side of the gateway. 

NOTE 2: There can, however, be an indirect impact on the H.323 side of the gateway, e.g. the initiation of call 
clearing procedures. 

The gateway shall handle the QSIG Channel identification information element in accordance with ECMA-143 [2] and 
shall not propagate this information element to the H.323 side of the gateway. 

The gateway shall handle locally any QSIG information elements from codesets other than codeset and shall not 
propagate these information elements to the H.323 side of the gateway. 

The QSIG Facility and Notification indicator information elements are outside the scope of ECMA-143 [2] and are 
therefore outside the scope of the present document. 

The gateway shall handle the H.225.0 STATUS and STATUS INQUIRY messages and the H.225.0 Call state 
information element in accordance with H.323 and H.225.0 and shall not propagate these items to the QSIG side of the 

gateway. 

NOTE 3: There can, however, be an indirect impact on the QSIG side of the gateway, e.g. the initiation of call 
clearing procedures. 
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The gateway shall handle locally any H. 225.0 messages and information elements that do not have QSIG equivalents 
specified in ECMA-143 [2] (e.g. USER INFORMATION message, Display information element) and shall not 
propagate these items to the QSIG side of the gateway. 

Interworking requirements for other messages and information elements are specified in the remainder of the present 
document. 

8.2 Call establishment from QSIG to H.323 

The gateway shall support call establishment using admission procedures as specified in clause 8.2.1. The gateway may 
also support call establishment without admission procedures as specified in clause 8.2.2 for use in the following 
circumstances: 

• if the gateway has not registered with a gatekeeper; or 

• if the gateway has registered with a gatekeeper and pre-granted admission applies for H.323 calls established by 
the gateway. 

8.2.1 Call establishment from QSIG to H.323 using admission procedures 

The gateway shall support call establishment using en bloc sending as specified in clause 8.2.1.1. The gateway shall 
support call establishment using QSIG overlap sending either: 

• by digit collection and the use of H.323 en bloc sending, as specified in clause 8.2.1.2; and/or 

• by using H.323 overlap sending, as specified in clause 8.2.1.3. 
Examples of message sequences are shown in clause B.2. 

8.2.1 .1 Call establishment from QSIG to H.323 using admission procedures and en 

bloc sending 

The following procedures apply when the gateway receives a QSIG SETUP message containing a Sending complete 
information element or the gateway receives a QSIG SETUP message and is able to determine that the number in the 
Called party number information element is complete. 

NOTE: The means by which the gateway determines the number to be complete is an implementation matter. It 
can involve knowledge of the numbering plan and/or the use of inter-digit timer expiry. 

8.2.1 .1 .1 Receipt of QSIG SETUP message 

On receipt of a QSIG SETUP message containing a number that the gateway determines to be complete in the Called 
party number information element, or containing a Sending complete information element if the gateway is unable to 
determine whether the number is complete, the gateway shall transmit an H. 225.0 ARQ message to the gatekeeper. The 
gateway shall include the contents of the QSIG SETUP message Called party number information element in the 
destinationlnfo element of the ARQ message using choice partyNumber. The gateway shall also transmit a QSIG CALL 
PROCEEDING message. 

On receipt of a QSIG SETUP message containing a Sending complete information element and a number that the 
gateway determines to be incomplete in the Called party number information element, the gateway shall initiate QSIG 
call clearing procedures using cause number 28 "invalid number format (address incomplete)". 

8.2.1 .1 .2 Receipt of H. 225.0 ACF message 

If in response to an H. 225.0 ARQ message for a call from QSIG the gateway receives an H. 225.0 ACF message, the 
gateway shall transmit an H. 225.0 SETUP message to the transport address contained in the destCallSignallingAddress 
element of the ACF message. 

For the Called party number information element and/or the destinationAddress element in the H. 225.0 SETUP 
(see clause 9.2), the gateway shall use the contents of the destinationlnfo element, if present in the ACF message. 
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The gateway shall either include element canOverlapSend with value FALSE in the H. 225.0 SETUP message or omit 
the element. 



8.2.1.1.3 



Receipt of H. 225.0 ARJ message 



If in response to an H. 225.0 ARQ message for a call from QSIG the gateway receives an H.225.0 ARJ message, the 
gateway shall initiate QSIG call clearing procedures. The gateway shall derive the QSIG cause number used from the 
rejectReason value in the H.225.0 ARJ message as specified in table 1. For rejectReason values not in table 1, the 
choice of appropriate QSIG cause number is an implementation matter (e.g. 31 "normal unspecified" or 41 "temporary 
failure"). 

Table 1 : Mapping of rejectReason values to cause numbers 



H.225.0 rejectReason value in ARJ 


QSIG cause number 


calledPartyNotRegistered 


20 "subscriber absent" 


requestDenied 


58 "bearer capability not presently available" 


resourceUnavailable 


47 "resource unavailable, unspecified" 


qosControlNotSupported 


49 "Quality of Service not available" 


incompleteAddress 


28 "invalid number format (address incomplete)" 


exceedsCallCapacity 


17 "user busy" 



8.2.1 .1 .4 Receipt of an H.225.0 CALL PROCEEDING message 

If the gateway receives an H.225.0 CALL PROCEEDING message, no action need be taken. 

8.2.1 .1 .5 Receipt of an H.225.0 ALERTING message 

If the gateway receives an H.225.0 ALERTING message it shall send a QSIG ALERTING message. 

8.2.1 .1 .6 Receipt of an H.225.0 CONNECT message 

If the gateway receives an H.225.0 CONNECT message it shall send a QSIG CONNECT message. 

8.2.1 .2 Call establishment from QSIG to H.323 using admission procedures and 

overlap sending in QSIG only 

The following procedures apply when the gateway receives a QSIG SETUP message containing no Sending complete 
information element, is able to determine that the number in the Called party number information element is incomplete 
and is able, as further digits are received, to determine when the number is complete. 

NOTE: The means by which the gateway determines the number to be complete is an implementation matter. It 
can involve knowledge of the numbering plan and/or the use of inter-digit timer expiry. 



8.2.1.2.1 



Receipt of OSIG SETUP message 



On receipt of a QSIG SETUP message containing no Sending complete information element, if the gateway determines 
that the number in the Called party number information element is incomplete it shall transmit a QSIG SETUP 
ACKNOWLEDGE message and await receipt of further number digits. 



8.2.1.2.2 



Receipt of OSIG INFORMATION message 



On receipt of a QSIG INFORMATION message while awaiting further number digits, the gateway shall append any 
number digits in the Called party number information element to those number digits already received and determine 
whether the resulting number is complete. If still incomplete and there is no Sending complete information element in 
the QSIG INFORMATION message, the gateway shall await further QSIG INFORMATION messages. If the number 
is still incomplete and the Sending complete information element is present in the QSIG INFORMATION message, the 
gateway shall initiate QSIG call clearing procedures using cause number 28 "invalid number format (address 
incomplete)". 
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8.2.1 .2.3 Transmission of H. 225.0 ARQ message 

When the gateway determines that the number received is complete, it shall transmit an H. 225.0 ARQ message to the 
gatekeeper with the contents of the Called party number information element from the QSIG SETUP message and 
appended number digits from QSIG INFORMATION messages in the destinationlnfo element of the ARQ using choice 
partyNumber. The gateway shall also transmit a QSIG CALL PROCEEDING message. 

8.2.1 .2.4 Receipt of H. 225.0 ACF message 

The requirements of clause 8.2.1.1.2 apply. 

8.2.1 .2.5 Receipt of H. 225.0 ARJ message 

The requirements of clause 8.2.1.1.3 apply. 

8.2.1 .2.6 Receipt of an H.225.0 CALL PROCEEDING message 

The requirements of clause 8.2.1.1.4 apply. 

8.2.1 .2.7 Receipt of an H.225.0 ALERTING message 

The requirements of clause 8.2.1.1.5 apply. 

8.2.1 .2.8 Receipt of an H.225.0 CONNECT message 

The requirements of clause 8.2.1.1.6 apply. 

8.2.1 .3 Call establishment from QSIG to H.323 using admission procedures and 

overlap sending in both QSIG and H.323 

The following procedures apply when the gateway receives a QSIG SETUP message containing no Sending complete 
information element, is unable to determine whether the number in the Called party number information element is 
complete and is unable, as further digits are received, to determine when the number is complete. 

8.2.1 .3.1 Receipt of OSIG SETUP message 

On receipt of a QSIG SETUP message containing no Sending complete information element, if the gateway is unable to 
determine whether the number in the Called party number information element is complete, the gateway shall transmit 
an H.225.0 ARQ message to the gatekeeper in accordance with clause 8.2.1.3.2. The gateway shall also transmit a 
QSIG SETUP ACKNOWLEDGE message. 

8.2.1 .3.2 Transmission of H.225.0 ARO message 

When transmitting an H.225.0 ARQ message to the gatekeeper, the gateway shall place the contents of the Called party 
number information element from the QSIG SETUP message and appended number digits from any QSIG 
INFORMATION messages in the destinationlnfo element of the ARQ message using choice partyNumber. 

NOTE: Appended number digits from QSIG INFORMATION messages apply only if this is not the first time an 
ARQ is sent (see clauses 8.2.1.3.5 and 8.2.1.3.6). 

8.2.1 .3.3 Receipt of OSIG INFORMATION message while awaiting response to H.225.0 
ARO message 

On receipt of a QSIG INFORMATION message while awaiting a response to an H.225.0 ARQ message, the gateway 
shall save the number digits from the Called party number information element. If the QSIG INFORMATION message 
contains a Sending complete information element, the gateway shall transmit a QSIG CALL PROCEEDING message. 
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8.2.1 .3.4 Receipt of H. 225.0 ACF message 

If in response to an H.225.0 ARQ message for a call from QSIG the gateway receives an H.225.0 ACF message, the 
gateway shall transmit an H.225.0 SETUP message to the transport address contained in the destCallSignallingAddress 
element of the ACF message. 

For the Called party number information element and/or the destinationAddress element in the H.225.0 SETUP 
(see clause 9.2), the gateway shall use the contents of the destinationlnfo element, if present in the ACF message, or 
otherwise the contents of the destinationlnfo element in the most recent ARQ message. In either case the gateway shall 
append any number digits saved from QSIG INFORMATION messages received since the H.225.0 ARQ message was 
transmitted. 

If a QSIG CALL PROCEEDING message has been sent, the gateway shall include a Sending complete information 
element in the H.225.0 SETUP message and omit element canOverlapSend. If a QSIG CALL PROCEEDING message 
has not been sent the gateway shall include element canOverlapSend with value TRUE and omit the Sending complete 
information element. 

8.2.1 .3.5 Receipt of H.225.0 ARJ message 

If in response to an H.225.0 ARQ message for a call from QSIG the gateway receives an H.225.0 ARJ message with 
value incompleteAddress in the rejectReason element, behaviour depends on whether further called party number digits 
have been received in QSIG INFORMATION messages since the H.225.0 ARQ message was sent and whether a QSIG 
CALL PROCEEDING message has been sent. If further digits have been received, the gateway shall transmit another 
H.225.0 ARQ message to the gatekeeper in accordance with clause 8.2.1.3.2. If no further digits have been received and 
no QSIG CALL PROCEEDING message has been sent, the gateway shall retain the call awaiting further called party 
number digits. Otherwise the gateway shall initiate QSIG call clearing procedures using cause number 28 "invalid 
number format (address incomplete)" in the QSIG Cause information element. 

If in response to an H.225.0 ARQ message for a call from QSIG the gateway receives an H.225.0 ARJ message with a 
value other than incompleteAddress in the rejectReason element, the gateway shall initiate QSIG call clearing 
procedures. The QSIG cause number used shall be derived from the rejectReason value in the H.225.0 ARJ message as 
specified in table 1 in clause 8.2.1.1.3. 

8.2.1 .3.6 Receipt of QSIG INFORMATION message following receipt of H.225.0 ARJ 
message with rejectReason incompleteAddress 

On receipt of a QSIG INFORMATION message following receipt of an H.225.0 ARJ message with rejectReason 
incompleteAddress, the gateway shall transmit another H.225.0 ARQ message to the gatekeeper in accordance with 
clause 8.2.1.3.2. If the QSIG INFORMATION message contains a Sending complete information element, the gateway 
shall transmit a QSIG CALL PROCEEDING message. 

8.2.1 .3.7 Receipt of OSIG INFORMATION message following transmission of H.225.0 
SETUP message 

On receipt of a QSIG INFORMATION message following transmission of an H.225.0 SETUP message and prior to 
receipt of any responding message, the gateway shall save the number digits from the Called party number information 
element. If the QSIG INFORMATION message contains a Sending complete information element, the gateway shall 
transmit a QSIG CALL PROCEEDING message. 

8.2.1 .3.8 Receipt of H.225.0 SETUP ACKNOWLEDGE message 

On receipt of an H.225.0 SETUP ACKNOWLEDGE message the gateway shall permit the transmission of H.225.0 
INFORMATION messages. If any QSIG INFORMATION messages have been received since transmission of the 
H.225.0 SETUP message, the gateway shall transmit an H.225.0 INFORMATION message in accordance with 
clause 8.2.1.3.10. 
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8.2.1 .3.9 Receipt of QSIG INFORMATION message following receipt of H. 225.0 SETUP 
ACKNOWLEDGE message 

On receipt of a QSIG INFORMATION message following receipt of an H.225.0 SETUP ACKNOWLEDGE message 
and prior to receipt of an H.225.0 CALL PROCEEDING, ALERTING, CONNECT or RELEASE COMPLETE 
message, the gateway shall transmit an H.225.0 INFORMATION message in accordance with clause 8.2.1.3.10. If the 
QSIG INFORMATION message contains a Sending complete information element, the gateway shall transmit a QSIG 
CALL PROCEEDING message. 

8.2.1.3.10 Transmission of H.225.0 INFORMATION message 

When transmitting an H.225.0 INFORMATION message, the gateway shall include the Called party number 
information element containing any number digits received from QSIG since the last H.225.0 message was transmitted 
(SETUP or INFORMATION), with other fields containing the same values as in the H.225.0 SETUP message. If a 
QSIG CALL PROCEEDING message has been sent, the gateway shall include a Sending complete information element 
in the H.225.0 INFORMATION message. 

8.2.1 .3.1 1 Receipt of an H.225.0 CALL PROCEEDING message 

If the gateway receives an H.225.0 CALL PROCEEDING message it shall stop sending H.225.0 INFORMATION 
messages. The gateway shall send a QSIG CALL PROCEEDING message if it has not already sent one. 

8.2.1.3.12 Receipt of an H.225.0 ALERTING message 

If the gateway receives an H.225.0 ALERTING message it shall stop sending H.225.0 INFORMATION messages and 
send a QSIG ALERTING message. 

8.2.1.3.13 Receipt of an H.225.0 CONNECT message 

If the gateway receives an H.225.0 CONNECT message it shall stop sending H.225.0 INFORMATION messages and 
send a QSIG CONNECT message. 

8.2.2 Call establishment from QSIG to H.323 without admission 
procedures 

If admission procedures are not used, the gateway is responsible for determining the call signalling transport address to 
which to send an H.225.0 SETUP message. This transport address can be: 

• the call signalling transport address of the gatekeeper with which the gateway is registered, if registered and 
using pre-granted admission for H.323 calls established by the gateway; or 

• the call signalling transport address of the destination endpoint or other entity able to take care of routing the call 
to the destination endpoint. 

NOTE: In the latter case, the means by which the transport address is determined is an implementation matter. 

The gateway shall support call establishment using en bloc sending as specified in clause 8.2.2.1. The gateway shall 
support call establishment using QSIG overlap sending either: 

• by digit collection and the use of H.323 en bloc sending, as specified in clause 8.2.2.2; and/or 

• by using H.323 overlap sending, as specified in clause 8.2.2.3. 
Examples of message sequences are shown in clause B.3. 
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8.2.2.1 Call establishment from QSIG to H.323 using en bloc sending and no 
admission procedures 

The following procedures apply when the gateway receives a QSIG SETUP message containing a Sending complete 
information element or the gateway receives a QSIG SETUP message and is able to determine that the number in the 
Called party number information element is complete. 

NOTE: The means by which the gateway determines the number to be complete is an implementation matter. It 
can involve knowledge of the numbering plan and/or the use of inter-digit timer expiry. 

8.2.2.1 .1 Receipt of QSIG SETUP message 

On receipt of a QSIG SETUP message containing a number that the gateway determines to be complete in the Called 
party number information element, or containing a Sending complete information element if the gateway is unable to 
determine whether the number is complete, the gateway shall attempt to determine the call signalling transport address 
to which to send an H. 225.0 SETUP message. 

If a call signalling transport address is determined, the gateway shall transmit an H. 225.0 SETUP message to that 
transport address. The gateway shall include the contents of the QSIG SETUP message Called party number 
information element in the H. 225.0 SETUP message in accordance with clause 9.2. The gateway shall either include 
element canOverlapSend with value FALSE in the H. 225.0 SETUP message or omit the element. The gateway shall 
also transmit a QSIG CALL PROCEEDING message. 

If the gateway is unable to determine a call signalling transport address, the gateway shall initiate QSIG call clearing 
procedures using cause number 1 "unallocated (unassigned) number", 3 "no route to destination" or 20 "subscriber 
absent". 

On receipt of a QSIG SETUP message containing a Sending complete information element and a number that the 
gateway determines to be incomplete in the Called party number information element, the gateway shall initiate QSIG 
call clearing procedures using cause number 28 "invalid number format (address incomplete)". 

8.2.2.1 .2 Receipt of an H.225.0 CALL PROCEEDING message 

The requirements of clause 8.2. LL4 apply. 

8.2.2.1 .3 Receipt of an H.225.0 ALERTING message 

The requirements of clause 8.2.1.L5 apply. 

8.2.2.1 .4 Receipt of an H.225.0 CONNECT message 

The requirements of clause 8.2. LL6 apply. 

8.2.2.2 Call establishment from QSIG to H.323 using overlap sending in QSIG only 
and no admission procedures 

The following procedures apply when the gateway receives a QSIG SETUP message containing no Sending complete 
information element, is able to determine that the number in the Called party number information element is incomplete 
and is able, as further digits are received, to determine when the number is complete. 

NOTE: The means by which the gateway determines the number to be complete is an implementation matter. It 
can involve knowledge of the numbering plan and/or the use of inter-digit timer expiry. 

8.2.2.2.1 Receipt of OSIG SETUP message 

On receipt of a QSIG SETUP message containing no Sending complete information element, if the gateway determines 
that the number in the Called party number information element is incomplete it shall transmit a QSIG SETUP 
ACKNOWLEDGE message and await receipt of further number digits. 
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8.2.2.2.2 Receipt of QSIG INFORMATION message 

On receipt of a QSIG INFORMATION message while awaiting further number digits, the gateway shall append any 
number digits in the Called party number information element to those number digits already received and determine 
whether the resulting number is complete. If still incomplete and there is no Sending complete information element in 
the QSIG INFORMATION message, the gateway shall await further QSIG INFORMATION messages. If the number 
is still incomplete and the Sending complete information element is present in the QSIG INFORMATION message, the 
gateway shall initiate QSIG call clearing procedures using cause number 28 "invalid number format (address 
incomplete)". 

If the gateway determines that the number is complete, the gateway shall attempt to determine the call signalling 
transport address to which to send an H. 225.0 SETUP message. 

If a call signalling transport address is determined, the gateway shall transmit an H. 225.0 SETUP message to that 
transport address. The gateway shall include the contents of the QSIG SETUP message Called party number 
information element, together with further digits received in QSIG INFORMATION messages, in the H. 225.0 SETUP 
message in accordance with clause 9.2. The gateway shall either include element canOverlapSend with value FALSE in 
the H.225.0 SETUP message or omit the element. The gateway shall also transmit a QSIG CALL PROCEEDING 
message. 

If the gateway is unable to determine a call signalling transport address, the gateway shall initiate QSIG call clearing 
procedures using cause number 1 "unallocated (unassigned) number", 3 "no route to destination" or 20 "subscriber 
absent". 

On receipt of a QSIG INFORMATION message containing a Sending complete information element and if the gateway 
determines the number, including appended digits, to be incomplete, the gateway shall initiate QSIG call clearing 
procedures using cause number 28 "invalid number format (address incomplete)". 

8.2.2.2.3 Receipt of an H.225.0 CALL PROCEEDING message 

The requirements of clause 8.2.1.1.4 apply. 

8.2.2.2.4 Receipt of an H.225.0 ALERTING message 

The requirements of clause 8.2.1.1.5 apply. 

8.2.2.2.5 Receipt of an H.225.0 CONNECT message 

The requirements of clause 8.2.1.1.6 apply. 

8.2.2.3 Call establishment from QSIG to H.323 using overlap sending in both QSIG 

and H.323 and no admission procedures 

The following procedures apply when the gateway receives a QSIG SETUP message containing no Sending complete 
information element, is unable to determine whether the number in the Called party number information element is 
complete and is unable, as further digits are received, to determine when the number is complete. 

8.2.2.3.1 Receipt of OSIG SETUP message 

On receipt of a QSIG SETUP message containing no Sending complete information element, the gateway shall try to 
determine the call signalling transport address to which to send the H.225.0 SETUP message, based on the digits 
received in the Called party number information element. 

If the gateway is unable to determine the call signalling transport address and does not require further digits in order to 
determine a call signalling transport address, the gateway shall initiate QSIG call clearing procedures using cause 
number 1 "unallocated (unassigned) number", 3 "no route to destination" or 20 "subscriber absent". 

If the gateway requires further digits to determine the call signalling transport address, the gateway shall transmit a 
QSIG SETUP ACKNOWLEDGE message and await further digits in INFORMATION messages. 
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If the gateway is able to determine the call signalling transport address but is unable to determine that the digits 
represent a complete number, the gateway shall transmit a QSIG SETUP ACKNOWLEDGE message. The gateway 
shall also transmit an H. 225.0 SETUP message to that transport address. The gateway shall include the contents of the 
QSIG SETUP message Called party number information element in the H. 225.0 SETUP message in accordance with 
clause 9.2. The gateway shall include element canOverlapSend with value TRUE in the H. 225.0 SETUP message. 

8.2.2.3.2 Receipt of QSIG INFORMATION message before transmitting an H. 225.0 
SETUP message 

On receipt of a QSIG INFORMATION message containing no Sending complete information element before 
transmitting an H. 225.0 SETUP message, the gateway shall append any additional number digits to those number digits 
already received and try to determine the call signalling transport address to which to send the H.225.0 SETUP 

message. 

If the gateway is unable to determine the call signalling transport address and does not require further digits in order to 
determine a call signalling transport address, the gateway shall initiate QSIG call clearing procedures using cause 
number 1 "unallocated (unassigned) number", 3 "no route to destination" or 20 "subscriber absent". 

If the gateway requires further digits to determine the call signalling transport address, the gateway shall await further 
digits in QSIG INFORMATION messages. 

If the gateway is able to determine the call signalling transport address but is unable to determine that the digits 
represent a complete number, the gateway shall transmit an H.225.0 SETUP message to that transport address. The 
gateway shall include the contents of the QSIG SETUP message Called party number information element, together 
with further digits received in QSIG INFORMATION messages, in the H.225.0 SETUP message in accordance with 
clause 9.2. The gateway shall include element canOverlapSend with value TRUE in the H.225.0 SETUP message. 

8.2.2.3.3 Receipt of OSIG INFORMATION message following transmission of H.225.0 
SETUP message 

The requirements of clause 8.2.1.3.7 shall apply. 

8.2.2.3.4 Receipt of H.225.0 SETUP ACKNOWLEDGE message 

The requirements of clause 8.2.1.3.8 shall apply. 

8.2.2.3.5 Receipt of OSIG INFORMATION message following receipt of H.225.0 SETUP 
ACKNOWLEDGE message 

The requirements of clause 8.2.1.3.9 shall apply. 

8.2.2.3.6 Transmission of H.225.0 INFORMATION message 

The requirements of clause 8.2.1.3.10 shall apply. 

8.2.2.3.7 Receipt of an H.225.0 CALL PROCEEDING message 

The requirements of clause 8.2.1.3.11 shall apply. 

8.2.2.3.8 Receipt of an H.225.0 ALERTING message 

The requirements of clause 8.2.1.3.12 shall apply. 

8.2.2.3.9 Receipt of an H.225.0 CONNECT message 

The requirements of clause 8.2.1.3.13 shall apply. 
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8.3 Call establishment from H.323 to QSIG 

Examples of message sequences are shown in clause B.4. 

8.3.1 Receipt of an H.225.0 SETUP message 

On receipt of an H.225.0 SETUP message the gateway shall carry out admission procedures in accordance with H.323 
unless either: 

• the gateway has not registered with a gatekeeper; or 

• the gateway has registered with a gatekeeper and pre-granted admission applies for H.323 calls arriving at the 
gateway. 

NOTE 1 : In accordance with H.323, unsuccessful admission results in rejection of the call or redirection of the call 
to the gatekeeper. In the latter case a further H.225.0 SETUP message will normally be received from the 
gatekeeper and will be handled as specified here, beginning with a further attempt at admission. 

On successful completion of admission procedures, or if admission procedures are not required, the gateway shall 
transmit a QSIG SETUP message. 

The gateway shall support call establishment using en bloc sending. The gateway may also support call establishment 
using H.323 and QSIG overlap sending. 

The gateway shall include the Sending complete information element in the QSIG SETUP message if any of the 
following circumstances applies: 

• the gateway does not support overlap sending; or 

• the H.225.0 SETUP message does not contain a canOverlapSend element or contains the element with value 
FALSE (see note 2); or 

• the H.225.0 SETUP message contains a Sending complete information element; or 

• the gateway is able to determine that the number included in the Called party number information element in the 
QSIG SETUP message is complete. 

NOTE 2: The canOverlapSend element indicates the calling endpoint's ability to support overlap sending. 

In other circumstances the gateway shall omit the Sending complete information element from the QSIG SETUP 
message and be prepared to engage in overlap sending procedures. 

If the gateway includes the Sending complete information element in the QSIG SETUP message, it shall respond to the 
H.225.0 SETUP message with an H.225.0 CALL PROCEEDING message. Otherwise it shall respond with an H.225.0 
SETUP ACKNOWLEDGE message. 

8.3.2 Additional messages relating to overlap sending 

The following procedure applies only if overlap sending is supported and the Sending complete information element 
was omitted from the QSIG SETUP message. 

8.3.2.1 Receipt of H.225.0 INFORMATION message following transmission of OSIG 

SETUP message 

On receipt of an H.225.0 INFORMATION message following transmission of a QSIG SETUP message and prior to 
receipt of any responding message, the gateway shall save the number digits from the Called party number information 
element. If the H.225.0 INFORMATION message contains a Sending complete information element, the gateway shall 
transmit an H.225.0 CALL PROCEEDING message. 



£75/ 



22 ETSI TS 102 036 V1.1.1 (2002-01) 

8.3.2.2 Receipt of QSIG SETUP ACKNOWLEDGE message 

On receipt of a QSIG SETUP ACKNOWLEDGE message the gateway shall permit the transmission of QSIG 
INFORMATION messages. If any H. 225.0 INFORMATION messages have been received since transmission of the 
QSIG SETUP message, the gateway shall transmit a QSIG INFORMATION message in accordance with 
clause 8.3.2.4. 

8.3.2.3 Receipt of H.225.0 INFORIVIATION message following receipt of QSIG 
SETUP ACKNOWLEDGE message 

On receipt of an H.225.0 INFORMATION message following receipt of a QSIG SETUP ACKNOWLEDGE message 
and prior to receipt of a QSIG CALL PROCEEDING, ALERTING, CONNECT, DISCONNECT, RELEASE or 
RELEASE COMPLETE message, the gateway shall transmit a QSIG INFORMATION message in accordance with 
clause 8.3.2.4. If the H.225.0 INFORMATION message contains a Sending complete information element, the gateway 
shall transmit an H.225.0 CALL PROCEEDING message. 

8.3.2.4 Transmission of OSIG INFORMATION message 

When transmitting a QSIG INFORMATION message, the gateway shall include the Called party number information 
element containing any number digits received in H.225.0 INFORMATION messages since the last QSIG message was 
transmitted (SETUP or INFORMATION), with other fields containing the same values as in the QSIG SETUP 
message. If an H.225.0 CALL PROCEEDING message has been sent, the gateway shall include a Sending complete 
information element in the QSIG INFORMATION message. 

8.3.3 Receipt of a QSIG CALL PROCEEDING message 

If the gateway receives a QSIG CALL PROCEEDING message it shall stop sending QSIG INFORMATION messages. 
The gateway shall send an H.225.0 CALL PROCEEDING message if it has not already sent one. 

8.3.4 Receipt of a QSIG ALERTING message 

If the gateway receives a QSIG ALERTING message it shall stop sending QSIG INFORMATION messages and send 
an H.225.0 ALERTING message. 

8.3.5 Receipt of a QSIG CONNECT message 

If the gateway receives a QSIG CONNECT message it shall stop sending QSIG INFORMATION messages and send an 
H.225.0 CONNECT message. It shall also respond with a QSIG CONNECT ACKNOWLEDGE message. 

8.4 PROGRESS messages and Progress indicator information 
elements 

8.4.1 Receipt of a Progress indicator information element in a QSIG 
message 

If the gateway receives a Progress indicator information element with coding standard value 00 (ITU-T standardized 
coding) in a QSIG ALERTING or CONNECT message, it shall forward the Progress indicator information element in 
the corresponding H.225.0 ALERTING or CONNECT message respectively. If the gateway receives a Progress 
indicator information element with coding standard value 00 (ITU-T standardized coding) in a QSIG PROGRESS 
message, it shall forward the Progress indicator information element in an H.225.0 PROGRESS message if the H.225.0 
call state permits. The gateway shall not forward a Progress indicator information element with coding standard 
value 01 (ISO/IEC standard) or a Progress indicator information element received in a QSIG SETUP message. 
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8.4.2 Receipt of a Progress indicator information element in an H. 225.0 
message 

If the gateway receives a Progress indicator information element in an H. 225.0 ALERTING or CONNECT message, it 
shall forward the Progress indicator information element in the corresponding QSIG ALERTING or CONNECT 
message respectively. If the gateway receives a Progress indicator information element in an H. 225.0 PROGRESS or 
CALL PROCEEDING message, it shall forward the Progress indicator information element in a QSIG PROGRESS 
message if the QSIG call state permits. 

8.4.3 Transmission of Progress indicator information element in support of 
gateway-provided ring-back tone 

When the gateway provides ring-back tone in accordance with clause 15, it shall include a Progress indicator 
information element containing progress description value 8 when transmitting a QSIG ALERTING message. 

8.5 Call clearing 

8.5.1 Call clearing initiated by QSIG 

On receipt of a QSIG DISCONNECT, RELEASE or RELEASE COMPLETE message that initiates call clearing, the 
gateway shall initiate H.323 call clearing procedures. 

NOTE: Where call admission procedures have been used, H.323 requires disengage procedures to be employed 
on call clearing. 

8.5.2 Call clearing initiated by H.323 

On receipt of an H. 225.0 RELEASE COMPLETE message or an H.245 EndSessionCommand, the gateway shall 
initiate QSIG call clearing procedures. 

NOTE: Where call admission procedures have been used, H.323 requires disengage procedures to be employed 
on call clearing. 



9 Numbering requirements 

9.1 Supported numbering plans and types of number 

The gateway shall comply with relevant aspects of ECMA-155 [3] for numbering within the PISN and shall accept the 
following values in the Numbering Plan Identification (NPI) field of QSIG Called party number. Calling party number 
and Connected number information elements: 

• Unknown; 

• ISDN/Telephony numbering plan (ITU-T Recommendations E.164 [11] and E.163 [12]); 

• Private Numbering Plan (PNP). 

The gateway shall also accept in these QSIG information elements any values of the Type Of Number (TON) field that 
have meaning (in accordance with ECMA-155 [3]) in conjunction with the particular value present in the NPI field. 
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The gateway shall also accept these NPI/TON combinations in H. 225.0 Called party number, Calling party number and 
Connected number information elements and shall accept equivalent information in H. 225.0 destinationlnfo (in ACF 
message), destinationAddress, sourceAddress and connectedAddress elements where: 

• choice dialedDigits is equivalent to NPI value unknown; 



• 



• 



• 



choice partyNumber.el64N umber is equivalent to NPI value ISDN/Telephony numbering plan (ITU-T 
Recommendations E. 164 [11] and E. 163 [12]); and 

• choice partyNumber.privateNumber is equivalent to NPI value Private Numbering Plan (PNP). 

9.2 Mapping numbers from QSIG to H.323 

The gateway shall have the capability to map a number received from QSIG to a number for transmission in H. 225.0 
without number translation and without change of NPI/TON values or equivalent. This requirement includes: 

• where admission procedures are used, mapping the contents of a QSIG Called party number information element 
in a QSIG SETUP message and any subsequent QSIG INFORMATION messages to an H.225.0 destinationlnfo 
element in an ARQ message (see note 1); 

where admission procedures are used, mapping the contents of a QSIG Calling party number information 
element in a QSIG SETUP message to an H.225.0 srclnfo element in an ARQ message; 

except where admission procedures are used and the received H.225.0 ACF message contains element 
destinationlnfo, mapping the contents of a QSIG Called party number information element in a SETUP message 
and any subsequent QSIG INFORMATION messages to an H.225.0 destinationAddress element in an H.225.0 
SETUP message and, unless the NPI field has value PNP, an H.225.0 Called party number information element 
in the same message (see notes 2 and 3); 

mapping the contents of a QSIG Called party number information in a QSIG INFORMATION message received 
after the sending of an H.225.0 SETUP message to an H.225.0 Called party number information element in an 
H.225.0 INFORMATION message; 

• mapping the contents of a QSIG Calling party number information element with a NPI value other than PNP in a 
QSIG SETUP message to an H.225.0 Calling party number information element in an H.225.0 SETUP message; 

• mapping the contents of a QSIG Calling party number information element with a NPI value of PNP in a QSIG 
SETUP message to an H.225.0 sourceAddress element in an H.225.0 SETUP message (see note 4); 

• mapping the contents of a QSIG Connected number information element in a QSIG CONNECT message to an 
H.225.0 Connected number information element in an H.225.0 CONNECT message. 

The above requirement does not prevent the gateway having the ability to perform number translation, provided it can 
be configured to operate without number translation. Means by which gateways can perform number translation are 
outside the scope of the present document. 

NOTE 1 : The destinationlnfo element is of the same type (Alias Address) as the destinationAddress element in call 
control messages, and therefore NPI equivalents are as specified above for destinationAddress. 

NOTE 2: Where destinationlnfo is present in the received H.225.0 ACF message, the alias address (or addresses) it 
contains is used in the H.225.0 SETUP message. 

NOTE 3: The special requirement for PNP numbers is in accordance with clause 7.2.2.4 of H.225.0 [6], which 
forbids the inclusion of number digits with NPI value PNP in the Called party number information 
element. H.323 still requires the gateway to generate an H.225.0 Called party number information 
element. In the absence of any other form of number available for inclusion, the information element can 
include all the contents of the QSIG Called party number information element with the exception of the 
digit field, which should be left empty. 
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NOTE 4: The special requirement for PNP numbers is in accordance with clause 7.2.2.6 of H. 225.0 [6], which 
forbids the inclusion of number digits with NPI value PNP in the Calling party number information 
element. H.323 still requires the gateway to generate an H. 225.0 Calling party number information 
element. In the absence of any other form of number available for inclusion, the information element can 
include all the contents of the QSIG Calling party number information element with the exception of the 
digit field, which should be left empty. 

When generating an H.225.0 Called party number information element, if the numbering plan is PNP the number digits 
shall be omitted. 

NOTE 5: This is in accordance with clause 7.2.2.4 of H.225.0 [6]. The NPI and TON fields are still present in the 
H.225.0 Called party number information element. The entire information from the QSIG Called party 
number information is available in the H.225.0 destinationAddress element. 

9.3 Mapping numbers from H.323 to QSIG 

The gateway shall have the capability to map a number received from H.225.0 to a number for transmission in QSIG 
without number translation and without change of NPI/TON values or equivalent. This requirement includes: 

• mapping the contents of an alias address in an H.225.0 destinationAddress element in an H.225.0 SETUP 
message to a QSIG Called party number information element in a QSIG SETUP message or, if 
destinationAddress contains no alias address that can be mapped, mapping the H.225.0 Called party number 
information element, if present; 

• where the only addresses able to be mapped from the H.225.0 destinationAddress element and the H.225.0 
Called party number information element in an H.225.0 SETUP message identify the gateway, mapping the 
contents of an alias address in an H.225.0 remoteExtensionAddress element, if present, to a QSIG Called party 
number information element in a QSIG SETUP message; 

• mapping the contents of an H.225.0 Called party number information in an H.225.0 INFORMATION message 
received after the sending of a QSIG SETUP message to a QSIG Called party number information element in a 
QSIG INFORMATION message; 

• mapping the contents of the Calling party number information element or an alias address in an H.225.0 
source Address element in an H.225.0 SETUP message to a QSIG Calling party number information element in a 
QSIG SETUP message (see note); 

• mapping the contents of the Connected number information element in an H.225.0 CONNECT message to a 
QSIG Connected number information element in a QSIG CONNECT message or, if the Connected number 
information element is not present, mapping a suitable alias address, if present in the H.225.0 connectedAddress 
element. 

The above requirement does not prevent the gateway having the ability to perform number translation, provided it can 
be configured to operate without number translation. Means by which gateways can perform number translation are 
outside the scope of the present document. 

NOTE: If more than one number can be mapped to the QSIG Calling party number information element, the 
choice of which to map is an implementation matter. 

9.4 Handling of presentation and screening indicators 

The gateway shall pass presentation and screening indicators associated with calling party and connected numbers 
transparently from QSIG to H.323 and vice versa. This includes the presentation indicator and screening indicator fields 
in QSIG and H.225.0 Calling party number and Connected number information elements. It also includes the H.225.0 
presentationlndicator and screeninglndicator elements when the numbers concerned are mapped to/from H.225.0 
sourceAddress and connectedAddress elements. 
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9.5 Handling of subaddresses 



The gateway shall not pass on in an H. 225.0 message any Called party subaddress, Calling party subaddress or 
Connected subaddress information element received in a QSIG message. 



10 Security requirements 



Within a PISN, QSIG signalling information is generally regarded as inherently secure and not subject to active attacks 
that can lead to denial or misuse of service. When interworking between QSIG and H.323, it is important to provide a 
similar level of security for H.323 signalling information, in order to prevent denial or misuse of service in the PISN. 

The gateway shall support the baseline security profile specified in annex D of ITU-T Recommendation H.235 [7] and 
shall use the profile's authentication and integrity mechanisms when communicating with a compliant gatekeeper, if 
required to do so by network policy and a shared secret key is available. This applies to H. 225.0 RAS signalling and to 
H. 225.0 call control signalling using the gatekeeper-routed model. The means for establishing shared secret keys is 
outside the scope of the present document. 

NOTE 1: This profile provides for authentication and integrity of H.225.0 messages (RAS and call control) 

between an endpoint (e.g. a gateway) and its gatekeeper using a shared secret key. Authentication and 
integrity of H.225.0 call control signalling automatically extends to any fast connect signalling and 
tunnelled H.245 signalling, but authentication and integrity of a separate H.245 channel is not provided. 

The use of the optional voice encryption profile, which is part of the basic security profile, is outside the scope of the 
present document. 

The use of authentication and integrity mechanisms for H.225.0 call control signalling directly to an H.323 entity other 
than the gatekeeper with which the gateway is registered (direct call signalling) is outside the scope of the present 
document. 

NOTE 2: This would not be scaleable, owing to the potentially very large number of shared secrets required. 

The ability to support alternative or additional security measures (e.g. public key infrastructure, transport layer or IP 
layer security) is not precluded but is outside the scope of the present document. 



1 1 Requirements for support of basic services 

The present document specifies signalling interworking for basic services that provide a bidirectional transfer capability 
for speech, facsimile and modem media between the two networks. These basic services are indicated in the QSIG 
Bearer capability information element by the field values shown in table 2. 
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Table 2: Field values within the QSIG Bearer capability information element for speech, 

facsimile and modem media 



Field 


Value 


Coding standard 


"ITU-T standardized coding" (00) 


Information transfer capability 


"speech" (00000) (see note 1 ), 
"unrestricted digital information" (01000) (see note 2), 
"restricted digital information" (01001) (see note 2), 
"3,1 kHz audio" (10000) (see note 1), 

"unrestricted digital information with tones and announcements" 
(10001) (see note 2) 


Transfer mode 


"circuit mode" (00) 


Information transfer rate 


"64 kbit/s" (10000) 


Multiplier 


Octet omitted 


User information layer 1 protocol 


"ITU-T Recommendation G.71 1 [13] M-law" (00010) or 
"ITU-T Recommendation G.71 1 [13] A-law" (0001 1) 


NOTE 1 : Information transfer capability "speech" is suitable only for speech, whereas information 
transfer capability "3,1 kHz audio" is suitable for speech, facsimile or modem data. 

NOTE 2: Information transfer capabilities "unrestricted digital information" and "restricted digital 

information" can be used for speech, in which case the user information layer 1 protocol will 
be present and coded as indicated in the table. Information transfer capability "unrestricted 
digital information with tones and announcements" can be used for speech when tones and 
announcements are present. These three types of bearer capability require no alteration to 
user information, thereby preventing the use of techniques such as compression. 



In addition, where QSIG is carried over an inter-PINX link that provides 16 kbit/s or 8 kbit/s user information channels 
in accordance with ECMA-253 [4] or ECMA-289 [5] respectively, other values can occur in the coding standard, 
information transfer rate and user information layer 1 fields as specified in those Standards. 

11.1 Calls from QSIG to H.323 

The gateway shall forward from QSIG to H.323 only calls in which the Bearer capability information element in the 
QSIG SETUP message has field values as shown in table 2 or as modified by ECMA-253 [4] or ECMA-289 [5]. The 
gateway shall reject other calls and may also reject calls for which the information transfer capability field has the value 
"unrestricted digital information", "restricted digital information" or "unrestricted digital information with tones and 
announcements". To reject a call, the gateway shall initiate QSIG call clearing procedures using cause number 65 
"bearer capability not implemented" in the QSIG Cause information element. 

When forwarding a call, the gateway shall pass on the QSIG Bearer capability information element unchanged as the 
H. 225.0 Bearer capability information element, with the following exception: fields coded in accordance with 
ECMA-253 [4] or ECMA-289 [5] shall be converted to values that conform with table 2. The gateway shall not pass on 
QSIG Low layer compatibility and High layer compatibility information elements. 

NOTE 1 : The speech encoding method used in the IP network is negotiated using H.245 or fast connect, and 
therefore the method and rate can differ from the method and rate indicated in the H. 225.0 Bearer 
capability information element (in this case G.711 and 64 kbit/s). 

NOTE 2: Use of a different speech encoding method in the IP network from that used in the QSIG network can 

result in the use of speech transcoding at the gateway. Speech transcoding can be avoided by negotiating 
in the IP network the same speech encoding that is used on the inter-PINX link. 

1 1 .2 Calls from H.323 to QSIG 

In the absence of other relevant information in the H. 225.0 SETUP message (e.g. fast connect), the gateway shall 
forward only calls in which the Bearer capability information element in the H.225.0 SETUP message has field values 
as shown in table 2. The gateway shall reject other calls and may also reject calls for which the information transfer 
capability field has the value "unrestricted digital information", "restricted digital information" or "unrestricted digital 
information with tones and announcements". To reject a call, the gateway shall initiate H.225.0 call clearing procedures 
using cause number 65 "bearer capability not implemented" in the H.225.0 Cause information element. 
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When forwarding a call from H.323 to QSIG, the gateway shall code the QSIG Bearer capability information element in 
accordance with table 2 or, for forwarding to an inter-PINX link that provides 16 kbit/s or 8 kbit/s user information 
channels, in accordance with ECMA-253 [4] or ECMA-289 [5] respectively. 

The gateway shall not include a Low layer compatibility in the QSIG SETUP message. The gateway shall not include a 
High layer compatibility information element in the QSIG SETUP message except as allowed in clause 13. 

NOTE 1 : The speech encoding method used in the IP network is negotiated using H.245 or fast connect, and 
therefore the method and rate can differ from the method and rate indicated in the H. 225.0 Bearer 
capability information element (in this case G.71 1 and 64 kbit/s). 

NOTE 2: Use of a different speech encoding method in the IP network from that used in the QSIG network can 

result in the use of speech transcoding at the gateway. Speech transcoding can be avoided by negotiating 
in the IP network the same speech encoding that is used on the inter-PINX link. 



12 Media channel establishment 

For basic services within the scope of the present document, except where special support for group 3 fax is being 
provided (see clause 13), each call requires in principle the use of two audio logical channels, one in each direction. 
However, calls can originate or terminate at H.323 endpoints that support only one-way audio (e.g. recorded 
announcement devices that transmit only). 

The gateway shall open and maintain an audio logical channel from itself to the peer endpoint, subject to the peer 
endpoint having acceptable audio receive capabilities, and accept the opening of an audio logical channel from the peer 
endpoint, subject to the peer endpoint using an audio transmit capability that is an acceptable receive capability at the 

gateway. 

NOTE 1 : The means for achieving this include fast connect, tunnelled H.245 and, when interworking with an 
endpoint that supports only H.323 version 3 or earlier, a separate H.245 channel. 

The gateway shall maintain a connection between each established audio logical channel and the corresponding user 
information channel on the inter-PINX link. 

The gateway may initiate call clearing in accordance with clause 8.5 if neither a transmit nor a receive audio logical 
channel can be opened. 

NOTE 2: Reasons for failing to establish an audio logical channel can include: 

the peer endpoint has no transmit or no receive audio capabilities; 

the peer endpoint's transmit or receive audio capabilities are incompatible with the gateway's audio 
capabilities; 

the gateway temporarily lacks resource compatible with the peer endpoint's transmit or receive 
capabilities. 

The gateway shall tolerate the closing and re-opening of audio logical channels during a call for reasons including but 
not necessarily limited to the following: change of codec, call hold, call transfer, conference formation, etc. However, 
the gateway may initiate call clearing in accordance with clause 8.5 in the event that audio logical channels cannot be 
re-opened for reasons listed above. 
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1 3 Requirements for the support of group 3 fax in 
accordance with H.323 annex D 

Gateway support for group 3 fax in accordance with H.323 [9] annex D is optional. If the gateway supports this 
capability, the requirements of this clause apply. 

13.1 Start of fax transmission 

The gateway shall be able to monitor audio information at the start of and during a call in order to detect the presence of 
fax and determine the negotiated transmission rate. If the gateway detects fax it shall close audio logical channel(s) (if 
open) and open fax logical channel(s) in accordance with H.323 [9] annex D. 

NOTE 1: For calls from QSIG to H.323, the QSIG SETUP message can contain a High layer compatibility 
information element indicating group 3 fax. However, the gateway still needs to monitor audio 
information to detect the transmission rate before opening fax logical channels. 

NOTE 2: H.323 [9] annex D provides the following options: two unidirectional logical channels using UDP, two 
unidirectional logical channels using TCP or one bidirectional logical channel using TCP. 

The gateway shall be able to co-operate in accordance with H.323 [9] annex D if the peer endpoint initiates the closing 
of audio logical channel(s) and the opening of fax logical channel(s) or the opening of fax logical channel(s) at the 
outset. 

For a call from H.323 to QSIG, if the gateway knows prior to sending the QSIG SETUP message that fax is being 
transmitted (e.g. because the opening of fax logical channels has been requested by means of fast connect), it may 
include in the QSIG SETUP message a High layer compatibility information element indicating group 3 fax. 

1 3.2 End of fax transmission 

The gateway may have the ability to detect the end of fax transmission. If the gateway detects the end of fax 
transmission it may close the fax logical channel(s) and open audio logical channel(s). 

The gateway shall be able to co-operate in accordance with H.245 [8] if the peer endpoint initiates the closing of fax 
logical channel(s) and the opening of audio logical channel(s). 



1 4 Requirements for the support of DTIVIF 

For a call from QSIG to H.323 or from H.323 to QSIG, a gateway shall be able to detect and generate DTMF tones 
corresponding to characters 0-9, A, B, C, D. * and # on the user information channel of the inter-PINX link. 

A gateway shall support the transmission and reception of H.245 userlnputlndication messages conveying characters 
to 9, A, B, C, D, * and #. 

A gateway may support the transmission and reception of characters to 9, A, B, C, D, * and # within RTP on special 
logical channels (one in each direction) in accordance with clause 10.5 of H.323 [9]. 

On detection of a DTMF tone from the inter-PINX link, the gateway shall send an H.245 userlnputlndication message 
conveying the character concerned, unless a logical channel for transmitting DTMF characters is open, in which case 
the gateway shall send the character using RTP on that logical channel. 

On receipt of a DTMF character in a userlnputlndication message or via RTP, the gateway shall generate a DTMF tone 
on the inter-PINX link. 
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1 5 Requirements for the provision of ring-back tone 

For a call from QSIG to H.323, if the gateway does not receive progress description value 1 or 8 in a Progress indicator 
information element in the H. 225.0 ALERTING message or an earlier H.225.0 message, the gateway shall provide 
ring-back tone towards the calling user. Ring-back tone shall commence when the QSIG ALERTING message is sent 
and shall terminate when the call is answered or cleared. 

NOTE 1: See clause 8.4.3 for requirements concerning the Progress indicator information element when providing 
ring-back tone. 

NOTE 2: For a call from QSIG to H.323, the called endpoint can provide ring-back tone while alerting the called 

user. If the gateway receives progress description value 1 or 8 in a Progress indicator information element 
in the H.225.0 ALERTING message or an earlier H.225.0 message, the gateway need not provide 
ring-back tone. 

NOTE 3: For a call from H.323 to QSIG, ring-back tone is normally provided by the PISN while alerting the called 
user. There are no gateway requirements for the provision of ring-back tone in this direction. 
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Annex A (normative): 

Implementation Conformance Statement (ICS) proforma 



Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that 
users of the present document may freely reproduce the ICS proforma in this annex so that it can be used for its 
intended purposes and may further publish the completed ICS. 



A.1 Introduction 

A.1 .1 Purpose of an ICS proforma 

The supplier of an implementation which is claimed to conform to the present document shall complete the following 
Implementation Conformance Statement (ICS) proforma. 

A completed ICS proforma is the ICS for the implementation in question. The ICS is a statement of which capabilities 
and options have been implemented for a given specification. 

The ICS can have a number of uses, including use: 

• by the implementor, as a check list for implementations to reduce the risk of unintended non-conformance, e.g. 
through oversight; 

• by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the 
capabilities of the implementation, stated relative to the common basis for understanding provided by the 
Standard's ICS proforma; 

• by the user or potential user of the implementation, as a basis for initially checking the possibility of 
interworking with another implementation - while interworking can never be guaranteed, failure to interwork can 
often be predicted from incompatible ICS ; 

• by a tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the 
implementation. 



A.2 Instructions for completing the ICS proforma 
A.2.1 General structure of the ICS proforma 

The ICS proforma is a fixed format questionnaire divided into sub-clauses each containing a group of individual items. 
Each item is identified by an item reference, the description of the item (question to be answered), and the reference(s) 
to the clause(s) that specifies (specify) the item in the main body of the present document. 

The "Conditions for Status" column contains a specification, if appropriate, of the predicate upon which a conditional 
status is based. The indication of an item reference in this column indicates a simple-predicate condition (support of this 
item is dependent on the support marked for the referenced item). 

The "Status" column indicates whether an item is applicable and if so whether support is mandatory or optional. The 
following terms are used: 

I irrelevant or out-of-scope - this capability is outside the scope of the standard to which this ICS 

proforma applies and is not subject to conformance testing in this context; 

M mandatory (the capability is required for conformance to the standard); 

N/A not applicable - in the given context, it is impossible to use the capability; no answer in the support 

column is required; 
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O optional (the capability is not required for conformance to the standard, but if the capability is 

implemented it is required to conform to the specification in the present document); 

0.<n> qualified optional - in this case, <n> is an integer that identifies a unique group of related optional 

items; if no additional qualification is indicated, the support of at least one of the optional items is 
required for conformance to the present document; otherwise, the qualification and logic of the 
selection among the optional items is defined below the table explicitly; 

X excluded or prohibited - there is a requirement not to use this capability in a given context. 

Answers to the questionnaire items are to be provided in the "Support" column, by simply marking an answer to 
indicate a restricted choice (Yes, No or N/A). In specific cases, the indication of explicit values may be requested. 
Where a support column box is left blank, no answer is required. 

If a "prerequisite line" (see clause A.2.4) is used after a clause heading or table title, and its predicate is false, no answer 
is required for the whole clause or table, respectively. 

A.2.2 Additional Information 

Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of 
the ICS. It is not intended or expected that a large quantity will be supplied, and an ICS can be considered complete 
without any such information. Examples might be an outline of the ways in which a (single) implementation can be set 
up to operate in a variety of environments and configurations. 

References to items of Additional Information may be entered next to any answer in the questionnaire, and may be 
included in items of Exception Information. 



A.2.3 Exception Information 



It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any 
conditions have been applied) in a way that conflicts with the indicated requirement. No pre-printed answer will be 
found in the Support column for this. Instead, the supplier is required to write into the support column an x.<i> 
reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. 

An implementation for which an Exception item is required in this way does not conform to the present document. A 
possible reason for the situation described above is that a defect in the Standard has been reported, a correction for 
which is expected to change the requirement not met by the implementation. 

A.2.4 Further indications of the ICS proforma tables 

In addition to the columns of a table, the following information may be indicated: 

"Prerequisite line" 

A prerequisite line after a clause heading or table title indicates that the whole clause or the whole table is not required 
to be completed if the predicate is false. 

"QuaHfication" 

At the end of a table, a detailed qualification for a group of optional items may be indicated, as specified in the 
description of the status "qualified optional" in clause A.2.1. 

"Comments" 

This box at the end of a table allows a supplier to enter any comments to that table. Comments may also be provided 
separately (without using this box). 
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A.3 Identification of the implementation 



A.3.1 Implementation Identification 



Table A.1 : Implementation Identification 



Supplier (see note 1) 




Contact point for queries about the ICS (see note 1 ) 




Implementation Name(s) and Version(s) 
(see notes 1 and 2) 




Other information necessary for full identification - 
e.g. name(s) and version(s) for machines and/or 
operating systems; System name(s) 





NOTE 1: Only the first three items are required for all implementations; other information may be completed as 
appropriate in meeting the requirement for full identification. 

NOTE 2: The terms Name and Version should be interpreted appropriately to correspond with a supplier's 
terminology (e.g. Type, Series, Model). 

A.3. 2 Specification for which this ICS applies 

Table A.2: Specification for which this ICS applies 



Title 


Corporate telecommunication networks - Signalling 
interworking between QSIG and H.323 - Basic services 


Version 


1.0 


Corrigenda Implemented (if applicable) 




Addenda Implemented (if applicable) 




Amendments Implemented (if applicable) 




Have any exception items been required? 


No[ ] Yes[ ] 

(The answer Yes means that the implementation does not 

conform to the present document) (see note) 


Date of Statement 




NOTE: In this case, an explanation shall be given of the nature of non-conformance either below or on a 
separate sheet of paper. 


Nature of non-conformance (if applicable): 
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A.4 Major options 



Table A.3: Major options 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MC1 


Support operation without registering with a 
gatel<eeper? 







7 


[]Yes[]No 


MC2 


Support pre-granted admission? 







7 


[ ]Yes [ ]No 


MC3 


Support overlap sending in QSIG only for 
calls from QSIG to H.323? 




0.1 


8 


[]Yes[]No 


MC4 


Support overlap sending in QSIG and H.323 
for calls from QSIG to H.323? 




0.1 


8 


[]Yes[]No 


MC5 


Support overlap sending from H.323 to 
QSIG? 







8 


[]Yes[]No 


MC6 


Use 16 kbit/s user information channels on 
the inter-PINX link In accordance with 
ECMA-253? 







11 


[]Yes[]No 


MC7 


Use 8 kbit/s user information channels on the 
inter-PINX link in accordance with 
ECMA-289? 







11 


[ ]Yes [ ]No 


MC8 


Support of fax in accordance with H.323 
annex D in IP network? 







13 


[]Yes[]No 


Comments: 





A. 5 General requirements 



Table A.4: General requirements 



Item 


Question: 
Does tlie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


GR1 


Support QSIG in accordance with 
ECMA-143? 




M 


7 


[]Yes 


GR2 


Support H.323 version 4 and H. 225.0 
version 4? 




M 


7 


[]Yes 


GR3 


Support interworking with other H.323 
entities in accordance with the provisions of 
H.323 version 4? 




M 


7 


[]Yes 


GR4 


Have an ability to discover and register with 
a gatekeeper? 




M 


7 


[]Yes 


GR5 


Support H.323 admission procedures during 
call establishment? 




M 


8.2.1 and 8.3 


[]Yes 


GR6 


Support call establishment without H.323 
admission procedures? 


MCI OR MC2 
NOT (MCI OR 
MC2) 


M 
X 


8.2.2 and 8.3 


[]Yes 


GR7 


Support H.323 direct call signalling? 




M 


7 


[]Yes 


GR8 


Support H.323 gatekeeper-routed signalling? 




M 


7 


[]Yes 


GR9 


Use of H.323 direct call signalling or H.323 
gatekeeper-routed signalling in accordance 
with instructions from the gatekeeper when 
registered with a gatekeeper and 
pre-granted admission does not apply? 




M 


7 


[]Yes 


GR10 


Support call establishment from QSIG to 
H.323? 




M 


7 


[]Yes 


GR11 


Support call establishment from H.323 to 
QSIG? 




M 


7 


[]Yes 


Comments: 
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A.6 Message validation and handling of protocol errors 

Table A.5: Message validation and handling of protocol errors 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MV1 


Validate received QSIG messages in 
accordance with ECI\/IA-143 and act in 
accordance with ECMA-143 on detection of 
a QSIG protocol error? 




M 


8.1 


[]Yes 


MV2 


Validate received H.225.0 messages in 
accordance with H.323 and H.225.0 and act 
in accordance with H.323 and H.225.0 on 
detection of an H.225.0 protocol error? 




M 


8.1 


[]Yes 


Comments: 



A.7 Call establishment from QSIG to H.323 with 
admission procedures and en bloc sending 

Table A.6: Call establishment from QSIG to H.323 with admission procedures 

and en bloc sending 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


QHA1 


Support receipt of QSIG SETUP message? 




M 


8.2.1.1.1 


[]Yes 


QHA2 


Support receipt of H.225.0 ACF message? 




M 


8.2.1.1.2 


[]Yes 


QHA3 


Support receipt of H.225.0 ARJ message? 




M 


8.2.1.1.3 


[]Yes 


QHA4 


Support receipt of H.225.0 ALERTING 
message? 




M 


8.2.1.1.5 


[]Yes 


QHA5 


Support receipt of H.225.0 CONNECT 
message? 




M 


8.2.1.1.6 


[]Yes 


Comments: 



£75/ 



36 



ETSI TS 102 036 V1.1.1 (2002-01) 



A.8 Call establishment from QSIG to H.323 with 

admission procedures and overlap sending in QSIG 
only 

Table A.7: Call establishment from QSIG to H.323 with admission procedures 
and overlap sending in QSIG only 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


QHA01 


Support receipt of QSIG SETUP message? 


MC3 


M 


8.2.1.2.1 


[]Yes 


NOT MC3 


N/A 




[]N/A 


QHA02 


Support receipt of QSIG INFORMATION 
message? 


MC3 


M 


8.2.1.2.2 


[lYes 


NOT MC3 


N/A 




[]N/A 


QHA03 


Support transmission of H.225.0 ARO 
message? 


MC3 


M 


8.2.1.2.3 


[]Yes 


NOT MC3 


N/A 




[]N/A 


QHA04 


Support receipt of H.225.0 ACF message? 


MC3 


M 


8.2.1.2.4 


[]Yes 


NOT MC3 


N/A 




[]N/A 


QHA05 


Support receipt of H.225.0 ARJ message? 


MC3 


M 


8.2.1.2.5 


[]Yes 


NOT MC3 


N/A 




[]N/A 


QHA06 


Support receipt of H.225.0 CALL 
PROCEEDING message? 


MC3 


M 


8.2.1.2.6 


[lYes 


NOT MC3 


N/A 




[]N/A 


QHA07 


Support receipt of H.225.0 ALERTING 
message? 


MC3 


M 


8.2.1.2.7 


[]Yes 


NOT MC3 


N/A 




[]N/A 


QHA08 


Support receipt of H.225.0 CONNECT 
message? 


MC3 


M 


8.2.1.2.8 


[]Yes 


NOT MC3 


N/A 




[]N/A 


Comments: 
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A.9 Call establishment from QSIG to H.323 with 

admission procedures and overlap sending in both 
QSIG and H.323 

Table A.8: Call establishment from QSIG to H.323 with admission procedures 
and overlap sending in both QSIG and H.323 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


QHA001 


Support receipt of QSIG SETUP message? 


MC4 


M 


8.2.1.3.1 


[]Yes 


NOT MC4 


N/A 




[]N/A 


QHA002 


Support transmission of H.225.0 ARQ 
message? 


MC4 


M 


8.2.1.3.2 


[lYes 


NOT MC4 


N/A 




[]N/A 


QHA003 


Support receipt of QSIG INFORMATION 
message while awaiting response to H.225.0 
ARQ message? 


MC4 


M 


8.2.1.3.3 


[]Yes 


NOT MC4 


N/A 




[]N/A 


QHA004 


Support receipt of H.225.0 ACF message? 


MC4 


M 


8.2.1.3.4 


[]Yes 


NOT MC4 


N/A 




[]N/A 


QHA005 


Support receipt of H.225.0 ARJ message? 


MC4 


M 


8.2.1.3.5 


[]Yes 


NOT MC4 


N/A 




[]N/A 


QHA006 


Support receipt of QSIG INFORMATION 
message following receipt of H.225.0 ARJ 
message with rejectReason 
incompleteAddress? 


MC4 


M 


8.2.1.3.6 


[lYes 


NOT MC4 


N/A 




[]N/A 


QHA007 


Support receipt of QSIG INFORMATION 
message following transmission of H.225.0 
SETUP message 


MC4 


M 


8.2.1.3.7 


[]Yes 


NOT MC4 


N/A 




[]N/A 


QHA008 


Support receipt of H.225.0 SETUP 
ACKNOWLEDGE message? 


MC4 


M 


8.2.1.3.8 


[lYes 


NOT MC4 


N/A 




[]N/A 


QHA009 


Support receipt of QSIG INFORMATION 
message following receipt of H.225.0 SETUP 
ACKNOWLEDGE message? 


MC4 


M 


8.2.1.3.9 


[]Yes 


NOT MC4 


N/A 




[]N/A 


QHAOO10 


Support transmission of H.225.0 
INFORMATION message? 


MC4 


M 


8.2.1.3.10 


[]Yes 


NOT MC4 


N/A 




[]N/A 


QHA001 1 


Support receipt of H.225.0 CALL 
PROCEEDING message? 


MC4 


M 


8.2.1.3.11 


[]Yes 


NOT MC4 


N/A 




[]N/A 


QHA0012 


Support receipt of H.225.0 ALERTING 
message? 


MC4 


M 


8.2.1.3.12 


[lYes 


NOT MC4 


N/A 




[]N/A 


QHA0013 


Support receipt of H.225.0 CONNECT 
message? 


MC4 


M 


8.2.1.3.13 


[]Yes 


NOT MC4 


N/A 




[]N/A 


Comments: 
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A.10 Call establishment from QSIG to H.323 using en bloc 
sending and no admission procedures 

Table A.9: Call establishment from QSIG to H.323 without admission procedures 

and en bloc sending 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


QHN1 


Support receipt of QSIG SETUP message? 


GR6 


M 


8.2.2.1.1 


[]Yes 


NOT GR6 


N/A 




[]N/A 


QHN2 


Support receipt of H.225.0 ALERTING 
message? 


GR6 


M 


8.2.2.1.3 


[]Yes 


NOT GR6 


N/A 




[]N/A 


QHN3 


Support receipt of H.225.0 CONNECT 
message? 


GR6 


M 


8.2.2.1.4 


[]Yes 


NOT GR6 


N/A 




[]N/A 


Comments: 





A.1 1 Call establishment from QSIG to H.323 using overlap 
sending in QSIG only and no admission procedures 

Table A.10: Call establishment from QSIG to H.323 using overlap sending in QSIG only 

and no admission procedures 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


QHN01 


Support receipt of QSIG SETUP message? 


GR6ANDMC3 


M 


8.2.2.2.1 


[]Yes 


N0T(GR6 AND 
MC3) 


N/A 




[]N/A 


QHN02 


Support receipt of QSIG INFORIVIATION 
message? 


GR6ANDMC3 


M 


8.2.2.2.2 


[]Yes 


N0T(GR6 AND 
MC3) 


N/A 




[]N/A 


QHN03 


Support receipt of H.225.0 CALL 
PROCEEDING message? 


GR6ANDMC3 


M 


8.2.2.2.3 


[lYes 


N0T(GR6 AND 
MC3) 


N/A 




[]N/A 


QHN04 


Support receipt of H.225.0 ALERTING 
message? 


GR6ANDMC3 


M 


8.2.2.2.4 


[]Yes 


N0T(GR6 AND 
MC3) 


N/A 




[]N/A 


QHN05 


Support receipt of H.225.0 CONNECT 
message? 


GR6ANDMC3 


M 


8.2.2.2.5 


[]Yes 


N0T(GR6 AND 
MC3) 


N/A 




[]N/A 


Comments: 
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A. 12 Call establishment from QSIG to H.323 using overlap 
sending in both QSIG and H.323 and no admission 
procedures 

Table A.11 : Call establishment from QSIG to H.323 using overlap sending in both QSIG 

and H.323 and no admission procedures 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


QHN001 


Support receipt of QSIG SETUP message? 


GR6ANDMC4 


M 


8.2.2.3.1 




N0T(GR6 AND 
MC4) 


N/A 






QHN002 


Support receipt of QSIG INFORMATION 
message before transmitting an H.225.0 
SETUP message? 


GR6ANDMC4 


M 


8.2.2.3.2 


[]Yes 


N0T(GR6 AND 
MC4) 


N/A 




[]N/A 


QHN003 


Support receipt of QSIG INFORIVIATION 
message following transmission of H.225.0 
SETUP message? 


GR6ANDMC4 


M 


8.2.2.3.3 


[]Yes 


N0T(GR6 AND 
MC4) 


N/A 




[]N/A 


QHN004 


Support receipt of H.225.0 SETUP 
ACKNOWLEDGE message? 


GR6ANDMC4 


M 


8.2.2.3.4 


[]Yes 


N0T(GR6 AND 
MC4) 


N/A 




[]N/A 


QHN005 


Support receipt of QSIG INFORMATION 
message following receipt of H.225.0 SETUP 
ACKNOWLEDGE message? 


GR6 AND MC4 


M 


8.2.2.3.5 


[]Yes 


N0T(GR6 AND 
MC4) 


N/A 




[]N/A 


QHN006 


Support transmission of H.225.0 
INFORMATION message? 


GR6ANDMC4 


M 


8.2.2.3.6 


[]Yes 


N0T(GR6 AND 
MC4) 


N/A 




[]N/A 


QHN007 


Support receipt of H.225.0 CALL 
PROCEEDING message? 


GR6 AND MC4 


M 


8.2.2.3.7 


[]Yes 


N0T(GR6 AND 
MC4) 


N/A 




[]N/A 


QHN008 


Support receipt of H.225.0 ALERTING 
message? 


GR6ANDMC4 


M 


8.2.2.3.8 


[]Yes 


N0T(GR6 AND 
MC4) 


N/A 




[]N/A 


QHN009 


Support receipt of H.225.0 CONNECT 
message? 


GR6ANDMC4 


M 


8.2.2.3.9 


[]Yes 


N0T(GR6 AND 
MC4) 


N/A 




[]N/A 


Comments: 
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A.13 Call establishment from H.323 to QSIG 

Table A.12: Call establishment from H.323 to QSIG 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


HQ1 


Support receipt of H.225.0 SETUP 
message? 




M 


8.3.1 


[]Yes 


HQ2 


Support receipt of H.225.0 INFORMATION 
message following transmission of OSIG 
SETUP message? 


MC5 


M 


8.3.2.1 


[]Yes 


NOT MC5 


N/A 




[]N/A 


HQ3 


Support receipt of OSIG SETUP 
ACKNOWLEDGE message? 


MC5 


M 


8.3.2.2 


[lYes 


NOT MC5 


N/A 




[]N/A 


HQ4 


Support receipt of H.225.0 INFORMATION 
message following receipt of QSIG SETUP 
ACKNOWLEDGE message? 


MC5 


M 


8.3.2.3 


[]Yes 


NOT MC5 


N/A 




[]N/A 


HQ5 


Support transmission of QSIG 
INFORMATION message? 


MC5 


M 


8.3.2.4 


[lYes 


NOT MC5 


N/A 




[]N/A 


HQ6 


Support receipt of QSIG CALL 
PROCEEDING message? 




M 


8.3.3 


[]Yes 


HQ7 


Support receipt of QSIG ALERTING 
message? 




M 


8.3.4 


[]Yes 


HQ8 


Support receipt of QSIG CONNECT 
message? 




M 


8.3.5 


[]Yes 


Comments: 



PROGRESS message and Progress indicator 
information elements 

Table A.13: PROGRESS message and Progress indicator information elements 



A.14 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


PR1 


Support receipt of Progress indicator 
information element in a QSIG message? 




M 


8.4.1 


[]Yes 


PR2 


Support receipt of Progress indicator 
information element in an H.225.0 message? 




M 


8.4.2 


[]Yes 


PR3 


Support transmission of Progress indicator 
information element in support of 
gateway-provided ring-back tone? 




M 


8.4.3 


[]Yes 


Comments: 
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A. 15 Call clearing 



Table A.14: Call clearing 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


CL1 


Support call clearing initiated by QSIG? 




M 


8.5.1 


[lYes 


CL2 


Support call clearing initiated by H.323? 




M 


8.5.2 


[]Yes 


Comments: 



A.16 Numbering requirements 

Table A.15: Numbering requirements 



Item 


Question: 
Does tfie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


NU1 


Provide support for numbering plans and 
types of numbers? 




M 


9.1 


[]Yes 


NU2 


Support mapping of numbers from QSIG to 
H.323? 




M 


9.2 


[]Yes 


NU3 


Support mapping of numbers from H.323 to 
QSIG? 




M 


9.3 


[]Yes 


NU4 


Handle presentation and screening 
indicators? 




M 


9.4 


[]Yes 


NU5 


Handle subaddresses? 




M 


9.5 


[]Yes 


Comments: 





A. 1 7 Security requirements 

Table A.16: Security requirements 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


SE1 


Support security requirements? 




M 


10 


[lYes 


Comments: 
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A. 18 Requirements for support of basic services 

Table A.I 7: Requirements for support of basic services 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


BS1 


Support basic services for calls from QSIG to 
H.323? 




M 


11.1 


[]Yes 


BS2 


Support basic services for calls from H.323 
to QSIG? 




M 


11.2 


[]Yes 


Comments: 



A.19 IVIedia channel establishment 



Table A.18: Media channel establishment 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


ME1 


Support media channel establishment? 




M 


12 


[]Yes 


Comments: 



A.20 Requirements for the support of group 3 fax in 
accordance with H.323 annex D 

Table A.19: Requirements for the support of group 3 fax in accordance with H.323 annex D 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


FAX1 


Support start of fax transmission? 


MC8 


M 


13.1 


[]Yes 


NOT MC8 


N/A 




[]N/A 


FAX2 


Support end of fax transmission? 


MC8 





13.2 


[]Yes 
[]No 


NOT MC8 


N/A 




[]N/A 


Comments: 
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A.21 Requirements for the support of DTMF 

Table A.20: Requirements for the support of DTMF 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MF1 


Support DTMF transmission from PISN to IP 
networl< and vice versa using H.245 
userlnputlndication messages in tlie IP 
network? 




M 


14 


[]Yes 


MF2 


Support DTMF transmission from PISN to IP 
network and vice versa using RTP on special 
logical channels in the IP network? 







14 


[]Yes 
[]No 


Comments: 



A.22 Requirements for the provision of ring-back tone 

Table A.21 : Requirements for the provision of ring-back tone 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


RBT1 


Provide ring-back tone towards a calling user 
in the PISN? 




M 


15 


[]Yes 


Comments: 
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Annex B (informative): 
Example message sequences 

B.1 Introduction 

This annex shows some typical message sequences that can occur. The message mapping requirements of clause 8 
permit variations on these sequences to occur. In each diagram QSIG messages are shown as arrows on the left side of 
the diagram and H. 225.0 messages are shown as arrows on the right side of the diagram. On the right hand side of the 
diagram, broken arrows represent H. 225.0 RAS messages and continuous arrows represent H. 225.0 call control 

messages. 

B.2 IVIessage sequences for call establishment from 
QSIG to H.323 using admission procedures 

Figures B.l to B.4 show typical sequences of messages for successful call establishment from QSIG to H.323 using 
admission procedures. 



PISN 



Gateway 



QSIG SETUP 



QSIG CALL PRQCEEDING 



QSIG ALERTING 



QSIG GQNNECT 



IP network 



H.225.0 ARQ 
H.225.0 ACF 



H.225.0 SETUP 



H.225.0 GALL PRQCEEDING 



H.225.0 ALERTING 



H.225.0 CQNNECT 



Figure B.1 : Typical message sequence for successful call establishment from QSIG to H.323 
using admission procedures and en bloc sending 
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PISN 


Gateway 


IP network 


QSIG SETUP 


■-....,..,. 






QSIG SETUP ACKNOWLEDGE 




QSIG INFORMATION 




QSIG INFORMATION 




OSIG CALL PROCEEDING 


H.225.0 ARC 




J^.225 


OACF 
SETUP 




H.225 




H.225.0 CALL PROCEEDING 


QSIG ALERTING 


H.225.0 ALERTING 






QSIG CONNECT 


H.225.0 CONNECT 


^ 











Figure B.2: Typical message sequence for successful call establishment from QSIG to H.323 
using admission procedures and overlap sending in QSIG 



PISN 



Gateway 



OSIG SETUP 



QSIG SETUP ACKNOWLEDGE 



OSIG INFORMATION 



OSIG INFORMATION 



OSIG CALL PROCEEDING 



OSIG ALERTING 



QSIG CONNECT 



IP network 



H.225.0 ARQ 

H.225.0 ARJ (incompleteAddress) 



H.225.0 ARQ 

H.225.0 ARJ (incompleteAddress) 
H.225.0 ARQ 
jj.225.0ACF 



H.225.0 SETUP 








H.225.0 CALL PROCEEDING 






H.225.0 ALERTING 








H.225.0 CONNECT 

< 





Figure B.3: Typical message sequence for successful call establishment from QSIG to H.323 
using admission procedures and overlap sending in both QSIG and H.323 (RAS only) 
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PISN 



Gateway 



QSIG SETUP 



QSIG SETUP ACKNOWLEDGE 



QSIG INFORMATION 



QSIG INFORMATION 



QSIG CALL PROCEEDING 



QSIG ALERTING 



OSIG CONNECT 



IP network 



H.225.0 ARO 

H.225.0 ARJ (IncompleteAddress) 

H.225.0 ARO 

H.225.0 ACF 

H.225.0 SETUP 



H.225.0 SETUP ACKNOWLEDGE 



H.225.0 INFORMATION 



H.225.0 CALL PROCEEDING 



H.225.0 ALERTING 



H.225.0 CONNECT 



Figure B.4: Typical message sequence for successful call establishment from QSIG to H.323 
using admission procedures and overlap sending in both QSIG and H.323 (RAS and call control) 



B.3 Message sequences for call establishment from 
QSIG to H.323 without admission procedures 

Figures B.5 to B.7 show typical sequences of messages for successful call establishment from QSIG to H.323 without 
admission procedures. 



PISN 


Gateway 


IP network 


QSIGS 


ETUP 




H.225 


n .9FTI IP 






QSIG CALL PROCEEDING 






H.225.0 CALL PROCEEDING 


QSIG ALERTING 


H ??5.0 ALERTING 


^ 




QSIG CONNECT 


H.225.0 CONNECT 


^ 






■ 





Figure B.5: Typical message sequence for successful call establishment from QSIG to H.323 
using en bloc sending (no admission procedures) 
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PISN 


Gateway 


IP network 


QSIG SETUP 








QSIG SETUP ACKNOWLEDGE 




QSIG INFORMATION 




QSIG INFORMATION 


H.225.0 SETUP 






QSIG GALL PROCEEDING 


H.225.0 CALL PROCEEDING 




^ 


QSIG ALERTING 


H.225.0 ALERTING 


^ 




QSIG CONNECT 


H.225.0 CONNECT 













Figure B.6: Typical message sequence for successful call establishment from QSIG to H.323 
using overlap sending in QSIG (no admission procedures) 



PISN 



Gateway 



QSIG SETUP 

► 

QSIG SETUP ACKNOWLEDGE 



QSIG INFORMATIO 



^ 



QSIG INFORMATION 



QSIG CALL PROCEEDING 



QSIG ALERTING 



QSIG CONNECT 



IP network 



H.225.0 SETUP 



H.225.0 SETUP ACKNOWLEDGE 



H.225.0 INFORMATION 



H.225.0 CALL PROCEEDING 



H.225.0 ALERTING 



H.225.0 CONNECT 



Figure B.7: Typical message sequence for successful call establishment from QSIG to H.323 
using overlap sending in both QSIG and H.323 (no admission procedures) 
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B.4 Message sequences for call establishment from 
H.323 to QSIG 

Figures B.8 and B.9 show typical sequences of messages for successful call establishment from QSIG to H.323. In these 
examples admission procedures are shown. 



PISN 



Gateway 



QSIG SETUP 



QSIG CALL PROCEEDING 



QSIG ALERTING 



QSIG CQNNECT 



IP network 



H.225.0 SETUP 



H.225.0 ARQ 
j.225.0 ACF 



H.225.0 CALL PROCEEDING 



H.225.0 ALERTING 



H.225.0 CONNECT 



Figure B.8: Typical message sequence for successful call establishment from H.323 to QSIG 
using admission procedures and en bloc sending 



PISN 


Gateway 


IP network 






H.225.0 SETUP 










H.225.0 ARQ 








QSIG SETUP 




H.225 


OACF 


^ 








QSIG SETUP ACKNOWLEDGE 




H.225.0 SETUP ACKNOWLEE 










QSIG INFORMATION 




H.225.0 INFORMATION 










QSIG INFORMATION 




H.225.0 INFORMATION 

< 


A 






QSIG CALL PROCEEDING 

► 




H.225.0 CALL PROCEEDING 






► 


QSIG ALERTING 

► 




H.225.0 ALERTING 






► 


QSIG CONNECT 

► 




H.225.0 CONNECT 










► 



Figure B.9: Typical message sequence for successful call establishment from H.323 to QSIG 
using admission procedures and overlap sending in both QSIG and H.323 
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B.5 Message sequences for call clearing 

Figures B. 10 and B. 1 1 show typical sequences of messages for call clearing. H.323 disengagement procedures are not 
shown. 



PISN 



Gateway 



QSIG DISCONNECT 



QSIG RELEASE 



QSIG RELEASE COMPLETE 



IP network 



H.225.0 RELEASE COMPLETE 



Figure B.10: Typical message sequence for call clearing initiated from PISN 



PISN 



Gateway 



QSIG DISCONNECT 



QSIG RELEASE 



QSIG RELEASE COMPLETE 



IP network 



H.225.0 RELEASE COMPLETE 



Figure B.11 : Typical message sequence for call clearing initiated from IP network 



£75/ 



50 ETSI TS 102 036 V1.1.1 (2002-01) 



Annex C (informative): 
Bibliography 



ECMA-30: "Corporate Telecommunication Networks - Signalling Interworking between QSIG and 
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ISO/IEC 21409)". 
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